---
display_title: "Don’t Use a CMS Until You Absolutely Need One"
meta_title: "When You Should (and Shouldn’t) Use a CMS"
meta_description: "Most teams adopt a CMS far too early. Here’s when a CMS actually makes sense—and why Git + MDX is often the faster, safer choice for early teams."
author: "John Jeong"
created: "2025-11-29"
published: true
---

There's this recurring mistake I see early teams make: they pick a CMS way too early.

Not because they need one. Not because their content is complicated. But because they feel like a "real company" is supposed to have a CMS.

It's the same energy as buying Jira before you have 5 engineers, or setting up a microservice before you have users. It feels official. Mature. Professional.

But it's fake work.

And it slows you down.

This post is Part 4 of our publishing series, and it's probably the most blunt one:

**Don't use a CMS until reality forces you to. Most teams don't need one. And you probably don't either.**

## 1. CMS Complexity Creeps Up Slowly and Quietly

Here's the curve:

- **Day 1:** "Let's use Sanity/Payload/GitBook, it looks nice."
- **Month 3:** "Our schema is getting a little complicated…"
- **Month 9:** "Why can't we just add this tiny field without breaking the entire model?"
- **Month 12:** "Migration failed. Again."
- **Month 24:** "Wait… can we ever leave this platform?"

The CMS becomes the product you have to maintain.

Not the tool you use.

## 2. CMS Systems Are Designed for Companies That Already Have a "Content Department"

Look closely at any enterprise CMS marketing page:

- roles
- permissions
- workflows
- approvals
- locales
- rich schemas
- omnichannel delivery
- asset pipelines
- collaborators
- audit logs

That's not for a team of three founders and one designer.

That's for companies that already have:

- a PM writing specs
- a marketing team writing pages
- a content manager building assets
- an editor reviewing drafts
- a legal team reviewing everything again

If you don't have that yet, you're building overhead before you have the team to need it.

## 3. Most Early-Stage Content Lives in Three Places: Your IDE, Your Head, or Your Repo

When you're small, content comes from:

- founders
- engineers
- product
- support
- whoever feels like writing that week

You aren't running a newsroom. You're building a product.

So why pick a tool built for newsrooms?

## 4. Writing Should Be Fast, Not "Structured"

The whole point of early-stage content is:

- communicate clearly
- ship quickly
- correct later
- move on

A CMS flips that energy:

- define model
- configure schema
- decide fields
- arrange layout
- create environment
- publish through abstraction

You end up spending more time setting up the publishing pipeline than actually publishing.

The best writing stacks make writing feel like thinking. A CMS makes writing feel like… filing a ticket.

## 5. CMS Lock-In Hurts Exactly When You Don't Have Time

You don't feel lock-in in Month 1. You feel it in Year 2:

- exports with weird block formats
- "portable text" that isn't portable
- HTML blobs with inline attributes
- API rate limits
- broken image references
- schema migrations that silently fail
- "upgrade your plan to unlock this feature"

At the exact moment when:

- you want to redesign the site
- you want to migrate to a new framework
- your content volume has grown
- you have no time to unravel technical debt

That's when your CMS taps you on the shoulder and says: "By the way, you can't leave."

## 6. Every CMS Introduces a Second Reality

A CMS creates two worlds:

- the "content world" (editor UI, schema models, drafts)
- the "code world" (MDX, components, styling, deployment)

You now maintain a mental bridge between both.

Every change travels across two systems:

- content updates → CMS
- component updates → code
- schema updates → both
- workflows → CMS
- build pipeline → code

Early teams can't afford that cognitive tax. You need one world, not two.

## 7. Git + MDX + IDE Will Take You Much Further Than You Think

People underestimate how far you can get with:

- a repo
- MDX
- an IDE
- a few components
- a preview environment
- GitHub PR flow

It scales surprisingly well:

- blogs
- docs
- changelogs
- guides
- handbooks
- landing pages
- tutorials
- API examples
- even product marketing pages if you build a few MDX components

Many companies you admire still run on file-based stacks:

- Vercel
- Supabase
- PlanetScale
- PostHog
- Expo

These aren't "toy setups." They are running content at world-class scale.

## 8. There Will Be a Time to Add a CMS — But Let That Moment Arrive Naturally

You'll know it when:

- non-engineers need to ship content independently
- you publish across multiple frontends (docs + app + website)
- you need localization / scheduling / workflows
- your content model is truly richer than Markdown
- a dedicated content team exists
- schema-based relationships actually matter

At that point:

- **Git-based CMS (Keystatic, Tina, Decap)** → Good first step. Adds UI without losing portability.
- **Headless CMS (Sanity, Payload)** → Only when you need cross-surface, omnichannel, or rich models.

But if you add any of these before you need them? They slow you down and trap you.

## 9. The Real Reason: You're Early. Stay Nimble.

A CMS is structure. Structure is stability. Stability is efficiency. Efficiency is for late-stage companies.

Speed is for early-stage companies. And speed comes from removing structure until the moment it stops working.

So don't over-engineer your publishing stack. Don't imitate companies 100x your size. Don't install enterprise workflows into a tiny team.

Just write. And ship. In the simplest system that respects your time.

You can add complexity later.

You cannot subtract it.

---

**This is Part 4 of our publishing series.**

1. [Why We Write Our Blog in an IDE](/blog/using-ide-for-writing)
2. [Why Our CMS Is GitHub](/blog/why-our-cms-is-github)
3. [Choosing a CMS in 2025](/blog/choosing-a-cms)
4. [Don't Use a CMS Until You Absolutely Need One](/blog/dont-use-a-cms) (You are here)
5. [Docs Edition: What to Use for Developer Documentation](/blog/developer-documentation-tools)
6. [How We Built Hyprnote's Publishing Stack](/blog/hyprnote-publishing-stack)
